Cumulative content of Working Group Meetings in 2023
Working Group Meeting
Date: 04/07/2023
Participants: Natalie Muric, Ansgar Mondorf, Eugen Costezki, Fred van Blommestein, Jostein Fromry, Peter, Pietro Palermo, Roschkowski Gregor, Wim Kok.
Model Editor: Andreea Pasăre
Note Editor: Jana Ahmad
Discussion
It was noted that the next steps of ePO development will be eAccess and ESPD models. It was mentioned that the data model in ESPD is represented using UML with non-specific relations between concepts.
During the meeting, the glossary for each module was presented. Each glossary contains all the related concepts, attributes, predicates (relations), and definitions. It was mentioned that when we have an external relation, it indicates a relation from an external module.
The alignment between PEPPOL business term requirements and ePO was also discussed. It was suggested to carry out this alignment during the Working Group Meetings, preferably every other Thursday, with a deadline set for the end of 2023.
To do this alignment, it was proposed to link ePO concepts that correspond to each BT, and the description of the BT would be the definition of the concept in ePO. It was clarified that a Business Term (BT) is the concept name in the business domain, while in ePO, it can refer to a concept, attribute, or predicate.
Examples from ePO were presented, such as the "Order" concept, which is a document with an identifier.
It was pointed out that to align concepts appropriately, the entire path of concepts should be mentioned, including inheritances. For example, the "Street Name" term should always be mapped to the street of an organization that is playing the agent in role.
The meeting also covered the issue date and issue time of an order. The dct:issued has a data type of rdfs:Literal which has been implemented as a xsd:dateTime datatype in ePO. rdfs:Literal includes xsd:dateTime.
During the meeting, it was noted that the ePO ontology, along with the glossary and documentation, will be published in the next couple of weeks.
Working Group meeting
Date: 20/06/2023
Participants: Natalie Muric,
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Discussion
The participants validated the new concepts in relation to the BTS found in the extended Annex of eForms. The BTs were mapped to the ePO ontology as follows, where the main bullet represents the BTs and the sub-bullets represent the corresponding ePO mapping:
-
BT-803: Notice Dispatch Date eSender
-
epo:Notice epo:hasESenderDispatchDate in epo:Notice.
-
-
BT-738: Notice Preferred Publication Date
-
epo:hasPreferredPublicationDate in epo:PublicationProvision
-
-
BT-578: Security Clearance
-
epo:isSecurityClearanceRequired property was created in epo:SecurityClearanceTerm
-
-
BT-801: Non-Disclosure Agreement
-
epo:NonDisclosureAgreementTerm class was created.
-
epo:isNonDisclosureAgreementRequired:boolean property was created on epo:NonDisclosureAgreementTerm.
-
-
BT-802: Non-Disclosure Agreement Description
-
dct:description on epo:NonDisclosureAgreementTerm concept.
-
-
BT-1371: Previous Planning Lot Identifier
-
This BT refers to the identifier of the Lot in the current Notice. The mapping for this BT should be coupled with the mapping from BT-1251. We also need to add a link between epo:PlannedProcurementPart and the epo:ProcurementObject (by using epo:foreseesProcurementObject relation).
-
-
1251: Previous Planning Lot Identifier
-
This refers to the identifier of the Previous PLannedProcurementPart; that will become the Lot from BT-1371.
-
Example of Implementation in ePO: (it was noted, this can be implemented in other ways).
-
epo-not:CompetitionNotice epo:refersToPrevious epo-not:PlanningNotice. epo-not:PlanningNotice epo:announcesPlannedProcurementPart epo:PlannedProcurementPart. epo:PlannedProcurementPart adms:identifier adms:Identifier.
-
-
Definitions:
During the meeting, the participants validated the definitions of the following terms:
-
epo:hasPublicationDate: Date of formal public issuance of the document.
-
dct:issued: Date of formal issuance of the resource. Additional information: This is generally used for modules other than eNotice.
Working Group meeting
Date: 13/06/2023
Participants: Natalie Muric, Giampaolo Sellitto
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Discussion:
The participants validated the monetary values in relation to the BTs in the extended Annex of eForms. The BTs were mapped to the ePO ontology as follows, where the main bullet represents the BTs and the sub-bullets represent the corresponding ePO mapping:
-
BT-27: Framework Maximum Value
-
epo:FrameworkAgreementTerm epo:hasLaunchFrameworkAgreementMaximumValue epo:MonetaryValue
-
-
BT-157: Group Framework Maximum Value
-
epo:FrameworkAgreementTerm epo:hasLaunchGroupFrameworkAgreementMaximumValue epo:MonetaryValue
-
epo:hasEstimatedValue was changed to epo:hasLaunchGroupFrameworkAgreementMaximumValue
-
-
BT-644: Prize Value
-
epo:Prize po:hasPrizeValue / epo:hasAmountValue epo:MonetaryValue .
-
-
BT-161: Notice Value
-
epo:NoticeAwardInformation epo:hasTotalAwardedValue epo:MonetaryValue
-
-
BT-118: Notice Framework Maximum Value
-
epo:NoticeAwardInformation epo:hasTotalAwardedValue epo:MonetaryValue
-
-
BT-1118: Notice Framework Approximate Value
-
epo:NoticeAwardInformation epo:hasApproximateFrameworkAgreementValue epo:MonetaryValue
-
-
BT-156: Group Framework Re-calculated Maximum Value
-
epo:LotGroupAwardInformation epo:hasGroupFrameworkAgreementMaximumValue epo:MonetaryValue
-
epo:hasGroupFrameworkAgreementAwardedValue was changed to epo:hasGroupFrameworkAgreementMaximumValue
-
-
BT-1561: Group Framework Re-estimated Value
-
epo:LotGroupAwardInformation epo:hasApproximateGroupFrameworkAgreementValue epo:MonetaryValue
-
-
BT-709: Framework Re-calculated Maximum Value
-
epo:LotAwardDecision epo:hasFrameworkAgreementMaximumValue epo:MonetaryValue
-
-
BT-660: Framework Re-estimated Value
-
epo:LotAwardDecision epo:hasApproximateFrameworkAgreementValue epo:MonetaryValue
-
epo:hasFrameworkAgreementEstimatedValue was changed to epo:hasApproximateFrameworkAgreementValue
-
-
BT-710: Tender Value Lowest
-
epo:SubmissionStatisticalInformation epo:hasLowestReceivedTenderValue epo:MonetaryValue
-
-
BT-711: Tender Value Highest
-
epo:SubmissionStatisticalInformation epo:hasHighestReceivedTenderValue epo:MonetaryValue
-
-
BT-720: Tender Value
-
epo:Tender epo:hasFinancialOfferValue epo:MonetaryValue
-
-
BT-779: Tender Payment Value
-
epo:ContractLotCompletionInformation epo:providesContractTotalPaymentValue epo:MonetaryValue
-
-
BT-782: Tender Penalties
-
epo:ContractLotCompletionInformation epo:providesContractTotalPenaltyValue epo:MonetaryValue
-
-
BT-162: Concession Revenue User
-
epo:ConcessionEstimate epo:hasEstimatedUserConcessionRevenue epo:MonetaryValue
-
-
BT-160: Concession Revenue Buyer
-
epo:ConcessionEstimate epo:hasEstimatedBuyerConcessionRevenue epo:MonetaryValue
-
-
BT-553: Subcontracting Value
-
epo:SubcontractingEstimate epo:hasSubcontractingEstimatedValue epo:MonetaryValue
-
-
BT-793: Review Remedy Value
-
epo:ReviewDecision epo:hasRemedyValue epo:MonetaryValue
-
-
BT-795: Review Request Fee
-
epo:ReviewRequest epo:hasReviewRequestFee epo:MonetaryValue
-
epo:paidReviewRequestFee was changed to epo:hasReviewRequestFee
-
Working Group meeting
Date: 01/06/2023
Participants: Natalie Muric, Glan Luigi Albano, Giovanna Filippone, Goncalo Negrao, Martina Pititto, Paolo De Lazzaro, Peter, Thomas Pettersson
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Discussion:
ePO module harmonisation
It was noted that the models had become easier to work with after the changes made during the previous post-award meeting. In the updated models, each line can now have a description and specify an item. The Information Hub has a direct link to the line, and the AllowanceChargeInformation could be defined at both the Document and Line levels.
The participants then discussed modeling virtual locations for service deliveries it was decided to use location based on coordinates, indicating a geographical location where the delivery could take place.
It was noted after the WGM that a virtual delivery location should be represented as a URL and further discussion is needed on this matter.
Contract
The Contract model was presented whereby a Contract is a Document and is subject to Contract Terms. It is signed by both the Contractor and the Buyer(s). It has reference to the Lot(s).
The contract model requirements were mapped to the ePO ontology as follows, where the main bullet represents the requirement, and the sub-bullets represent the corresponding ePO mapping:
-
Contract
-
epo:Contract
-
-
Contract identifier
-
epo:Contract adms:identifier adms:identifier
-
-
Contract issue date:
-
Dct:issued in epo:Document
-
-
Contract issue time
-
Dct:issued in epo:Document
-
-
Contract type
-
At-voc:contract-nature codelist. But it was noted that, it does not cover for FA or DPS needs to be checked. Also, Reference number of the contract needs to be checked.
-
-
Process control
-
In the meeting, it was noted that Process control is not applicable in data-oriented modelling (ePO)
-
-
Contracting body
-
epo:Buyer
-
-
Economic operator
-
epo:Contractor
-
-
Procurement project name
-
Dct:title on epo:Contract
-
-
Procurement project description
-
Dct:description on epo:Contract
-
-
Procurement project type
-
uses contract-nature on ContractTerms
-
-
Estimated total value
-
is at the ProcurementObject level.
-
-
Description of extension and options:
-
epo:hasOptionsDescription on ContractTerms
-
-
CPV
-
at-voc:cpv codelist at Contract level
-
-
CPV
-
supplementary is not included in ePO
-
-
Procurement project location NUTS code
-
epo:ContractTerm epo:definesPlaceOfPerformance dct:Location
-
dct:Location epo:hasNutsCode at-voc:nuts
-
Period start date
-
epo:ContractTerm epo:definesContractPeriod epo:Period
-
-
Period start time
-
epo:ContractTerm epo:definesContractPeriod epo:Period
-
-
Period end date
-
epo:ContractTerm epo:definesContractPeriod epo:Period
-
-
Period end time
-
epo:ContractTerm epo:definesContractPeriod epo:Period
-
-
Lot identifier
-
epo:Contract epo:hasLotReference epo:Lot
-
-
Award criterion type
-
epo:Lot epo:specifiesProcurementCriterion epo:AwardCriterion epo:hasAwardCriterionType at-voc:award-criterion-type
-
-
Legal references
-
epo:Lot epo:hasLegalBasis at-voc:legal-basis OR epo:hasLegalBasisDescription on epo:ProcurementObject
-
-
Tender identifier
-
epo:Contract epo:includesTender epo:Tender
-
-
Tender digest
-
epo:hasElectronicDigest
-
-
Tender signature
-
epo:hasElectronicSignature
-
-
Tender total amount:
-
epo:Tender epo:hasFinancialOfferValue epo:MonetaryValue
-
-
Tender total taxes amount:
-
epo:Tender epo:hasTaxInformation epo-ord:TaxInformation epo-cat:hasAmount
-
It was noted a conflict in the definitions of Tender total taxes amount and Tender total amount in the in contract model requirements.
-
Tender total amount: The total amount of the offered deliverables in the tender excluding all taxes payable by the contracting authority.
-
Tender total taxes amount: The total amount of taxes included in the total amount.
-
-
-
Award identifier:
-
epo:AwardDecision adms:identifier adms:Identifier
-
-
Award date
-
epo:hasAwardDecisionDate (by using xsd:dateTime attribute)
-
-
Award time
-
epo:hasAwardDecisionDate (by using xsd:dateTime attribute)
-
-
Winner economic operator
-
epo:Winner
-
-
Economic operator name
-
dct:title on the foaf:Agent
-
-
Economic operator identifier:
-
adms:identifier on the foaf:Agent
-
-
Economic operator registration country code:
-
org:Organization epo:hasRegistrationCountry at-voc:country.
-
-
Documents:
-
epo:Document epo:associatedWith epo:Document
-
epo:Contract is an epo:Document
-
-
Attachment identifier:
-
adms:identifier on epo:Document
-
-
Attachment description:
-
dct:description on epo:Document
-
-
Attached document
-
We do not provide the binary object, only URL (epo:hasAccessURL on the epo:Document)
-
-
Deliverable offered
-
epo:Contract epo:specifiesDeliverable epo:Item
-
-
Deliverable name
-
dct:title on the epo:Item
-
-
Deliverable description
-
dct:description on the epo:Item
-
-
Delivered quantity
-
epo:Deliverable epo-cat:hasQuantity epo:Quantity
-
-
Deliverable total amount
-
epo:Deliverable epo:hasTotalValue epo:MonetaryValue The model below was validated.
-
The property epo:hasAccessURL has been removed from the Contract class because it was inherited from the Document class.
The property epo:hasHomePage was changed to epo:hasInternetAddress in cpov:ContactPoint class.
It was noted that epo:hasInternetAddress is used in various places
-
cpov:ContactPoint epo:hasInternetAddress
-
Org: Organization epo:hasInternetAddress
-
Org: Organization epo:hasPrimaryContactPoint cpov:ContactPoint The epo:hasInternetAddress was defined:
epo:hasInternetAddress: The main webpage used by the instance of the concept.
It was noted that the Contract class needs to have its own estimated value, as it is not considered a Procurement Element. This is to distinguish between the Tender value and the Contract value. As a result, the Contract now includes the relation epo:hasContractValue to capture the value associated with the contract. This property is linked to the epo:MonetaryValue class. Additionally, the Contract has a lot reference through the property "epo:hasLotReference" which connects it to the epo:Lot class.
Further discussion is needed to determine how to model Monetary Values with respect to both Contract and Tender.
The Contract class has an Amended Contract subclass. The Amended Contract class inherits all attributes from the Contract class.
The following Notices were discussed, and it was suggested to update the Notice modules accordingly to implement them.
-
Contract Completion Notice Announcement of the completion of a contract The main purpose of this notice is to understand if the contract was completed as set out in the contract award notice (to be published on 2023-06-14 in EU Vocabularies) It was noted that the Completion Notice announces the completion of the Contract, not the Contract itself. Therefore: epo:announcesContract was changed to epo:announcesCompletionOfContract.
-
Pre-Market Consultation Notice Announcement of a pre-market consultation. A pre-market consultation is not a call for competition, and no procurement documents are available at the time of consultation. A consultation may or may not be followed by a future competition (to be published 2023-06-14 in EU Vocabularies).
Action Points
-
Points to be followed up
-
What is the Reference number of the contract
-
The conflict in the definitions of Tender total taxes amount and Tender total amount needs to be addressed.
-
Tender total amount: The total amount of the offered deliverables in the tender excluding all taxes payable by the contracting authority.
-
Tender total taxes amount: The total amount of taxes included in the total amount.
-
-
Contract type is mapped to at-voc:contract-nature codelist (works, service and supplies) in ePO. However in the contract model requirements contract type can also be FA and DPS it should be checked if there is a valid reason for this?
-
Update the Notice modules to implement Contract Completion Notice and Pre-Market Consultation Notice.
-
Working Group meeting 30/05/2023
Date: 30/05/2023
Participants: Natalie Muric, Giampaolo Sellitto.
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Agenda
-
Continue discussing Dynamic Purchasing System (DPS) model
-
Relations and properties definition harmonisation.
-
epo-cat:hasAmount
-
epo:hasValidityPeriod
-
dct:title
-
skos:prefLabel
-
dct:Description
Discussion
During the WGM meeting, the modeling of Award Decisions within the Framework Agreement and Dynamic Purchasing System (DPS) ontology following the previous meeting. Based on this discussion, the following updates were made:
-
epo:announcesLotAwardOutcome was changed to epo:announcesLotAwardDecision.
-
epo:ResultNotice epo:announcesLotAwardDecision epo:AwardDecision should be visible in Notice module
-
epo:comprisesLotAwardOutcome was changed to epo:comprisesLotAwardDecision
The participants defined the following terms and relations:
-
epo:SubmissionStatisticalInformation: Statistical information about submissions on a given competition, either at Lot level or Mini-Competition level.
-
epo:MiniCompetitionAwardDecision: Result concerning the Mini-Competition attributed by the Awarder
-
epo:summarisesInformationForAwardDecision: Relates to submission for the given competition, either at Lot level or Mini-Competition level.
The model below was validated:
Framework Agreement
The participants reviewed and validated the following model:
A Framework Agreement results from a Lot Award Decision, which concerns a specific Lot that uses the framework technique. The Lot Award decision which is used to establish the Framework Agreement specifies the different Qualification Criterion and Award Criterion (Procurement Criterion) to be used. The Mini Competition that may be launched within the Framework Agreement follows the rules set by the Framework Agreement and involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
During the meeting, it was confirmed that technique is used at lot level.
The relation epo:indicatesAwardOfLotToWinner was changed to epo:indicatesAwardToWinner to accommodate the award of mini-competitions.
Furthermore, the participants defined the following terms:
epo:MiniCompetition: A process where multiple winners or candidates of previous stages of a procedure bid for a specific procurement. Additional Information:
It is typically used in framework agreements where the suppliers have already been pre-selected, and the mini competition is used to determine which supplier is best suited for a particular project or contract. It is also used in a Dynamic Purchasing System where the suppliers come from a list of Candidates.
epo:QualificationCriterion: Criterion used in the first stage of procurement.
epo:ParticipationCondition: Criterion that describes a Requirement to take part in a procurement.
DPS:
The DPS diagram below was reviewed and validated by the participants:
A DPS (Dynamic Purchasing System) uses a DPS Technique. In the first stage, the different Qualification Criterion are specified and there is no Award Decision, however a Candidate List is created which lists the economic operators that are admitted to subsequent Mini-Competitions. The subsequent Mini Competitions involve specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
During the WGM, a question was raised regarding whether "epo:DynamicPurchasingSystem" should be a subclass of "epo:system." The decision was to leave it for the time being and if the need became apparent this would be implemented.
-
Additionally, epo:CandidateList was changed to epo:SelectedCandidateList and its definition is updated to the following definition: Record of Candidates admitted to take part in award phases of procurements.
-
epo:Candidate: The Role of an Agent that has sought an invitation or has been invited to take part in a restricted Procedure, in a competitive Procedure with negotiation, in a negotiated Procedure without prior publication, in a competitive dialogue or in an innovation partnership.
Relation and property definition harmonisation.
The following relations and properties occur in the ontology with more than one definition the participants therefore agreed on a common definition for each
epo-cat:hasAmount: The predetermined monetary value charged in addition to the price.
-
epo:hasValidityPeriod: The relation indicating until when a given instance of a concept is applicable.
-
epo:hasCertification: Relation to the proof of conformance.
-
dct:description: An account of the resource. Additional Information: Description may include, but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource.
-
dct:title: A name given to the resource.
-
skos:prefLabel: The preferred lexical label for a resource, in a given language. (it has been added as issue into GitHub)
-
For the relation epo-cat:has Amount one of the relations had a definition and the others not so the one existing definition was pasted in all: The predetermined monetary value charged in addition to the price. After meeting note: however this definition should be further reviewed.
Action
Add the following changes to the ticket titled "Review changes that affect the standard form mappings."
-
epo:announcesLotAwardOutcome was changed to epo:announcesLotAwardDecision.
-
epo:comprisesLotAwardOutcome was changed to epo:comprisesLotAwardDecision
-
epo:indicatesAwardOfLotToWinner was changed to epo:indicatesAwardToWinner.
Working Group meeting 23/05/2023
Date: 23/05/2023
Participants: Natalie Muric, Giovanna Filippone, Martina Pititto, Giampaolo Sellitto
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Agenda
-
Discuss Dynamic Purchasing System (DPS) model
-
Is there an actual Award Decision in the DPS after the Qualification Stage, even if there is no Contract Award Notice?
Discussion
The WGM started by introducing the participants to the scope of the ePO ontology, which aims to provide a formal representation of the concepts, relationships, and entities within the eProcurement domain. It aims to facilitate the exchange of procurement-related information between different systems and organizations, and to support the automation and optimization of procurement processes. The ontology covers various aspects of procurement, such as procurement notification, tendering, contracting, and invoicing and is data oriented.
The modeling of Framework Agreement and Dynamic Purchasing System (DPS) within the ontology was presented.
Framework Agreement
A Framework Agreement results from a Lot Award Decision, which concerns a specific Lot that uses the framework technique. The Lot Award decision which is used to establish the Framework Agreement specifies the different Qualification Criterion and Award Criterion (Procurement Criterion) to be used. The Mini Competition that may be launched within the Framework Agreement follows the rules set by the Framework Agreement and involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:
DPS
A DPS (Dynamic Purchasing System) uses a DPS Technique. In the first stage, the different Qualification Criterion are specified and there is no Award Decision, however a Candidate List is created which lists the economic operators that are admitted to subsequent Mini-Competitions. The subsequent Mini Competitions involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:
Award Decision:
To ensure Award Decisions exist for both the Framework Agreement and the Mini Competitions the Award Decision has become a superclass of Lot Award Decision and Mini Competition Award Decision allowing for the different instantiations required for different use cases. The Award Decision comprises Tender Award Outcome which indicates award of Lot to a winner. These relations are inherited by the Lot Award Decision and Mini Competition Award Decision. See diagram below.
After meeting note: as the Mini Competition inherits from the Award Decision the relation “indicatesAwardOfLotToWinner” needs to be reviewed maybe to “indicatesAwardToWinner”
During the WGM, the relations describesLot and describesMiniCompetition were changed to concernsLot and concernsMiniCompetition respectively. Additionally, the relations, epo:hasRestated AwardedValue and epo:hasRestatedEstimatedValue were removed from the model.
Definitions:
During the meeting, the participants defined the following terms:
-
epo:hasBargainPrice: The value of procured supplies that have used a particularly advantageous opportunity available for a very short time at a value considerably lower than normal market prices.
-
DPS: An electronic System that is set up by a Buyer which lists the Economic Operators that satisfy the Qualification Criteria, which may later be put into competition via a Mini-Competition in view of awarding a Purchase Contract.
-
DynamicPurchaseSystemTechniqueUsage: A Technique that allows the selection of Candidates throughout the Procedure via the Qualification Criteria, followed by individual Mini-Competitions for the Award of Purchase Contracts.
-
ListCanditate: A list of Candidates considered to take part in a restricted Procedure, in a competitive Procedure with negotiation, in a negotiated Procedure without prior publication, in a competitive dialogue or in an innovation partnership.
Working Group meeting 16/05/2023
Date: 16/05/2023
Participants: Natalie Muric, Pietro Palermo, Peter Borresen, Thomas Pettersson.
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Agenda
Harmonization of modules for eCatalogue, eFulfilment, and eOrdering Modules
-
Charge Information - Item Level or Line Level?
-
Item and Batch IDs
-
Organisation and Person Certificates
-
Remodelling epo-ord:DeliveryTerm
Discussion
The working group began by reviewing previous agreements related to eCatalogue, eOrdering, and eFulfilment modules reached in meetings held on April 25, 27, and May 3, 2023.The participants confirmed their consensus on the proposed changes.
-
Removal of epo-cat:hasExternalSpecification property in the epo-cat:item in Catalogue module
-
Standardised namespace prefix for ePO Model (Note: in the text and diagrams in this report the standardised namespace of epo: has not been used as the standardized namespace is to implemented with all other changes.)
-
Renaming epo-cat:ItemDescription to epo:ItemProperty.
-
Replacing epo-ful:hasBaseAmount property with epo:isCalculatedOn in epo-ord:AllowanceChargeInformation and epo-ord:TaxInformation . Replace epo-cat:specifiesItem relationship between epo:Deliverable and epo-cat:Item by inheritance of epo-cat:Item by epo:Deliverable.
-
epo:Contractor and epo-ord:Seller are the same concepts in a Public Procurement.
-
epo-ord:AllowanceChargeInformation will have 3 subclasses: epo-ord:AllowanceInformation, epo-ord:ChargeInformation, and epo-ord:PriceDiscountInformation, because epo-ord:AllowanceChargeInformation is an epo-cat:InformationHub, and it is directly connected to the Line and Document.
-
The VAT rate value will be modeled through epo-ord:TaxInformation epo-cat:hasPercentage and epo-ord:TaxInformation epo-cat:hasTaxCategory. The working group then continued to discuss the points that were seen as contentious previously:
Charge Information - Item Level or Line Level?
During the discussion, participants debated whether the Charge Information should be at the Item level or Line level. To illustrate the point an example of countries where certain charges are associated with food items containing sugar. For instance, if an item is priced at 1 euro, the actual amount paid might be 1.7 euros due to the sugar charge. This charge is applied at the price level.
One suggestion put forward was to have the price at the item level, establishing a direct association between the item and its price. However, after further deliberation, the decision was made to maintain the price at the line level while establishing a reference between the line and the item.
In PEPPOL the price is specified based on the location, and the order reflects the price based on quantities. There are two types of discounts: line-level discounts and price-level discounts. Line-level discounts can be defined as a specific amount per line, such as a discount of 100 euros per line. Price-level discounts, on the other hand, are expressed as a certain amount per unit, such as cents per orange.
As a result of the discussion, it was decided to remove the epo-ord:PriceDiscountInformation element and introduce new associations for enhanced clarity and consistency. The new associations are epo-ord:hasPriceDiscountInformation between epo-cat:Price and epo-ord:isSpecificToOrderLine, as well epo:hasPriceSurchargeInformation between epo-cat:Price and epo-cat:ChargeInformation.
Modeling of Item and Batch IDs
The participants agreed to replace the relation adms:identifier with epo:hasBatchID to improv clarity and consistency. The epo: hasCatalogueItemID is replaced by epo:hasSellerItemID
As part of the discussion, it was agreed to add definitions for all epo:Item and epo:Batch IDs:
-
epo:hasManufacturerItemID: The general identifier assigned to the concept as defined by the manufacturer.
-
epo:hasBuyerItemID: The general identifier assigned to the concept as defined by the Buyer.
-
epo:hasBatchID: The identifier assigned to a specific batch of the produced Item.
-
epo:hasSellerItemID: The general identifier for the concept as defined by the seller.
-
epo:hasSerialID: The identifier assigned to the specific instance of the produced concept.
To illustrate these concepts, an example was discussed: when purchasing a new mobile phone, the seller ID and the manufacturer ID may differ, but a generic buyer ID would be used.
Organisation and Person Certificates
It was agreed upon by the participants to introduce the epo:hasCertification relation between epo:Certificate and epo:Organization, epo:Person, and epo:Item. This new relation allows for the association of certifications with these entities.
Furthermore, the definitions for the following concepts were updated as follows:
-
epo:Certifier: A Role of an Agent that issues a Certificate.
-
epo:Certificate: Proof of conformance of the instance of the concept to a defined set of criteria, ensuring credibility, trust and transparency.
Remodelling epo-ord:DeliveryTerm
During the working group meeting, it was agreed by the participants to rename the entity epo-ord:DeliveryTerm to epo-ord:DeliveryAgreement. By changing the name of the concept there is no conflict with the Term hierarchy of the ontology and the original modelling can be reused. The update was made directly in the meeting.
.
Revising Definitions
The participants revised the definitions with respect to the concepts that were discussed during the meeting.
-
epo-ord:DeliveryAgreement: Term applying to the delivery of goods, services and works. Additional Information: Delivery terms identifier can normally be Incoterms accompanied by the description of specific conditions related to the delivery.
-
epo-cat:InformationHub: Grouping of data that may be associated to various concepts. Additional Information: For example, AllowanceChargeInformation may be associated to the Order or the Catalogue (either at the Line level or at the Document level), amongst others.
-
epo-cat:ChargeInformation: Information about tax, fee or duty imposed. Additional Information: Charge category indicates the nature of the tax/duty/fee, for example VAT, CAR, etc. Charge category modifier may be used in case different levels, exemptions or other modifications apply. The charge can be fixed or relative to the price.
-
epo-ord:AllowanceChargeInformation: Information about discounts, taxes, duties and fees imposed.
-
epo-ord:AllowanceInformation: Information about the discounts imposed.
Action Points:
-
Remove epo-ord:PriceDiscountInformation and introduce new associations:
-
epo-cat:Price epo-ord:hasPriceDiscountInformation epo-ord:isSpecificToOrderLine
-
epo-cat:Price epo:hasPriceSurchargeInformation epo-cat:ChargeInformation.
-
Update definitions for all epo:Item and epo:Batch IDs
-
Organisation and Person Certificates:
-
Update the definition of epo:Certifier and epo:Certificate.
-
Introduce new associations:
-
epo:Person epo:hasCertification epo:Certificate
-
org:Organization epo:hasCertification epo:Certificate
-
epo:Item epo:hasCertification epo:Certificate
Working Group meeting
Date: 01/08/2023
Participants: Natalie Muric, Arillo Aranda Paloma, Pascaline Laure Tchienehom
Model editor: Andreea Pasăre
Note editor: Alexandros Vassiliades
Discussion:
-
Can we consider the ESPD Business Handbook (ESPD Request part only) as requirements for eAccess?
-
Discuss the following statement: It is not necessary for Buyers and Economic Operators to create a new ESPD document for each procedure. Instead, it is possible to re-use an ESPD in different procurement procedures, facilitating the tasks of users.
Reuse in the previous sentence also implies partial reuse of the content in the xml file. Paloma will change the previous sentence in order to reflect the actual meaning more accurately.
Requirements of ESPD and the eAccess should not be considered the same. We should
-
A new property from ESPDResponse to ESPDRequest was created (epo-sub:relatesToESPDRequest):
-
The Lot is defined at the ESPDResponse level as depicted in the image below:
-
Though it is not sure that the ESPDRequest can be related to more than one Procedures. It was implicitly agreed that each ESPDRequest will have its own Procedure since an ESPDRequest will have its own identifier for each Procedure.
-
Going through the attributes from ESPDRequest concept in ESPD model:
-
ReferenceNumber does not need to be covered in ePO
-
DocumentVersionIdentifier exists as epo:hasVersion at the Document level in ePO
-
Discussion over the various types of dates that exist on the ESPD class:
-
An ESPD is published and not issued
-
In ePO we have epo:hasPublicationDate at the Document level, but the data type do not allow us to also store the time, only the date; and for an ESPD we need both date and time
-
-
CopyIndicator should be removed but is still in the UML diagram of ESPD. This concept does not seem to be needed in ePO also.
-
-
The relation between epo:ESPDRequest and epo:Buyer seems an overkill as they are related through the epo:Procedure, and it was removed.
-
We need to provide an identifier for Criteria, so this means that cccev:Requirement should be connected through a relation (adms:identifier) with adms:Identifier. But CCCEV provides identifiers as a literal attribute on the concepts. Added an action point to discuss whether we can reuse CCCEV and ADMS concepts like this.
-
epo:ProcurementCriterion was connected by relation epo-acc:implementsLegislation with epo-acc:Legislation and by relation epo-acc:implementsArticle with epo-acc:Article.
-
The legislation part for Criterion is implemented as depicted in the image below:
Action point:
-
Discuss on the need to change epo:hasPublicationDate on epo:Document
-
Check if the cccev:InformationConcept and adms:Identifier can be connected between them. Because here we have a concept from an ontology A (cccev:InformationConcept) and a concept through an ontology B (adms:Identifier), connected between them. Same case for cccev:Requirement and adms:identifier
Working Group meeting
Date: 13/06/2023
Participants: Natalie Muric, Giampaolo Sellitto
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Discussion:
The participants validated the monetary values in relation to the BTs in the extended Annex of eForms. The BTs were mapped to the ePO ontology as follows, where the main bullet represents the BTs and the sub-bullets represent the corresponding ePO mapping:
-
BT-27: Framework Maximum Value
-
epo:FrameworkAgreementTerm epo:hasLaunchFrameworkAgreementMaximumValue epo:MonetaryValue
-
-
BT-157: Group Framework Maximum Value
-
epo:FrameworkAgreementTerm epo:hasLaunchGroupFrameworkAgreementMaximumValue epo:MonetaryValue
-
epo:hasEstimatedValue was changed to epo:hasLaunchGroupFrameworkAgreementMaximumValue
-
-
BT-644: Prize Value
-
epo:Prize po:hasPrizeValue / epo:hasAmountValue epo:MonetaryValue .
-
-
BT-161: Notice Value
-
epo:NoticeAwardInformation epo:hasTotalAwardedValue epo:MonetaryValue
-
-
BT-118: Notice Framework Maximum Value
-
epo:NoticeAwardInformation epo:hasTotalAwardedValue epo:MonetaryValue
-
-
BT-1118: Notice Framework Approximate Value
-
epo:NoticeAwardInformation epo:hasApproximateFrameworkAgreementValue epo:MonetaryValue
-
-
BT-156: Group Framework Re-calculated Maximum Value
-
epo:LotGroupAwardInformation epo:hasGroupFrameworkAgreementMaximumValue epo:MonetaryValue
-
epo:hasGroupFrameworkAgreementAwardedValue was changed to epo:hasGroupFrameworkAgreementMaximumValue
-
-
BT-1561: Group Framework Re-estimated Value
-
epo:LotGroupAwardInformation epo:hasApproximateGroupFrameworkAgreementValue epo:MonetaryValue
-
-
BT-709: Framework Re-calculated Maximum Value
-
epo:LotAwardDecision epo:hasFrameworkAgreementMaximumValue epo:MonetaryValue
-
-
BT-660: Framework Re-estimated Value
-
epo:LotAwardDecision epo:hasApproximateFrameworkAgreementValue epo:MonetaryValue
-
epo:hasFrameworkAgreementEstimatedValue was changed to epo:hasApproximateFrameworkAgreementValue
-
-
BT-710: Tender Value Lowest
-
epo:SubmissionStatisticalInformation epo:hasLowestReceivedTenderValue epo:MonetaryValue
-
-
BT-711: Tender Value Highest
-
epo:SubmissionStatisticalInformation epo:hasHighestReceivedTenderValue epo:MonetaryValue
-
-
BT-720: Tender Value
-
epo:Tender epo:hasFinancialOfferValue epo:MonetaryValue
-
-
BT-779: Tender Payment Value
-
epo:ContractLotCompletionInformation epo:providesContractTotalPaymentValue epo:MonetaryValue
-
-
BT-782: Tender Penalties
-
epo:ContractLotCompletionInformation epo:providesContractTotalPenaltyValue epo:MonetaryValue
-
-
BT-162: Concession Revenue User
-
epo:ConcessionEstimate epo:hasEstimatedUserConcessionRevenue epo:MonetaryValue
-
-
BT-160: Concession Revenue Buyer
-
epo:ConcessionEstimate epo:hasEstimatedBuyerConcessionRevenue epo:MonetaryValue
-
-
BT-553: Subcontracting Value
-
epo:SubcontractingEstimate epo:hasSubcontractingEstimatedValue epo:MonetaryValue
-
-
BT-793: Review Remedy Value
-
epo:ReviewDecision epo:hasRemedyValue epo:MonetaryValue
-
-
BT-795: Review Request Fee
-
epo:ReviewRequest epo:hasReviewRequestFee epo:MonetaryValue
-
epo:paidReviewRequestFee was changed to epo:hasReviewRequestFee
-
Working Group meeting
Date: 01/06/2023
Participants: Natalie Muric, Glan Luigi Albano, Giovanna Filippone, Goncalo Negrao, Martina Pititto, Paolo De Lazzaro, Peter, Thomas Pettersson
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Discussion:
ePO module harmonisation
It was noted that the models had become easier to work with after the changes made during the previous post-award meeting. In the updated models, each line can now have a description and specify an item. The Information Hub has a direct link to the line, and the AllowanceChargeInformation could be defined at both the Document and Line levels.
The participants then discussed modeling virtual locations for service deliveries it was decided to use location based on coordinates, indicating a geographical location where the delivery could take place.
It was noted after the WGM that a virtual delivery location should be represented as a URL and further discussion is needed on this matter.
Contract
The Contract model was presented whereby a Contract is a Document and is subject to Contract Terms. It is signed by both the Contractor and the Buyer(s). It has reference to the Lot(s).
The contract model requirements were mapped to the ePO ontology as follows, where the main bullet represents the requirement, and the sub-bullets represent the corresponding ePO mapping:
-
Contract
-
epo:Contract
-
-
Contract identifier
-
epo:Contract adms:identifier adms:identifier
-
-
Contract issue date:
-
Dct:issued in epo:Document
-
-
Contract issue time
-
Dct:issued in epo:Document
-
-
Contract type
-
At-voc:contract-nature codelist. But it was noted that, it does not cover for FA or DPS needs to be checked. Also, Reference number of the contract needs to be checked.
-
-
Process control
-
In the meeting, it was noted that Process control is not applicable in data-oriented modelling (ePO)
-
-
Contracting body
-
epo:Buyer
-
-
Economic operator
-
epo:Contractor
-
-
Procurement project name
-
Dct:title on epo:Contract
-
-
Procurement project description
-
Dct:description on epo:Contract
-
-
Procurement project type
-
uses contract-nature on ContractTerms
-
-
Estimated total value
-
is at the ProcurementObject level.
-
-
Description of extension and options:
-
epo:hasOptionsDescription on ContractTerms
-
-
CPV
-
at-voc:cpv codelist at Contract level
-
-
CPV
-
supplementary is not included in ePO
-
-
Procurement project location NUTS code
-
epo:ContractTerm epo:definesPlaceOfPerformance dct:Location
-
dct:Location epo:hasNutsCode at-voc:nuts
-
Period start date
-
epo:ContractTerm epo:definesContractPeriod epo:Period
-
-
Period start time
-
epo:ContractTerm epo:definesContractPeriod epo:Period
-
-
Period end date
-
epo:ContractTerm epo:definesContractPeriod epo:Period
-
-
Period end time
-
epo:ContractTerm epo:definesContractPeriod epo:Period
-
-
Lot identifier
-
epo:Contract epo:hasLotReference epo:Lot
-
-
Award criterion type
-
epo:Lot epo:specifiesProcurementCriterion epo:AwardCriterion epo:hasAwardCriterionType at-voc:award-criterion-type
-
-
Legal references
-
epo:Lot epo:hasLegalBasis at-voc:legal-basis OR epo:hasLegalBasisDescription on epo:ProcurementObject
-
-
Tender identifier
-
epo:Contract epo:includesTender epo:Tender
-
-
Tender digest
-
epo:hasElectronicDigest
-
-
Tender signature
-
epo:hasElectronicSignature
-
-
Tender total amount:
-
epo:Tender epo:hasFinancialOfferValue epo:MonetaryValue
-
-
Tender total taxes amount:
-
epo:Tender epo:hasTaxInformation epo-ord:TaxInformation epo-cat:hasAmount
-
It was noted a conflict in the definitions of Tender total taxes amount and Tender total amount in the in contract model requirements.
-
Tender total amount: The total amount of the offered deliverables in the tender excluding all taxes payable by the contracting authority.
-
Tender total taxes amount: The total amount of taxes included in the total amount.
-
-
-
Award identifier:
-
epo:AwardDecision adms:identifier adms:Identifier
-
-
Award date
-
epo:hasAwardDecisionDate (by using xsd:dateTime attribute)
-
-
Award time
-
epo:hasAwardDecisionDate (by using xsd:dateTime attribute)
-
-
Winner economic operator
-
epo:Winner
-
-
Economic operator name
-
dct:title on the foaf:Agent
-
-
Economic operator identifier:
-
adms:identifier on the foaf:Agent
-
-
Economic operator registration country code:
-
org:Organization epo:hasRegistrationCountry at-voc:country.
-
-
Documents:
-
epo:Document epo:associatedWith epo:Document
-
epo:Contract is an epo:Document
-
-
Attachment identifier:
-
adms:identifier on epo:Document
-
-
Attachment description:
-
dct:description on epo:Document
-
-
Attached document
-
We do not provide the binary object, only URL (epo:hasAccessURL on the epo:Document)
-
-
Deliverable offered
-
epo:Contract epo:specifiesDeliverable epo:Item
-
-
Deliverable name
-
dct:title on the epo:Item
-
-
Deliverable description
-
dct:description on the epo:Item
-
-
Delivered quantity
-
epo:Deliverable epo-cat:hasQuantity epo:Quantity
-
-
Deliverable total amount
-
epo:Deliverable epo:hasTotalValue epo:MonetaryValue The model below was validated.
-
The property epo:hasAccessURL has been removed from the Contract class because it was inherited from the Document class.
The property epo:hasHomePage was changed to epo:hasInternetAddress in cpov:ContactPoint class.
It was noted that epo:hasInternetAddress is used in various places
-
cpov:ContactPoint epo:hasInternetAddress
-
Org: Organization epo:hasInternetAddress
-
Org: Organization epo:hasPrimaryContactPoint cpov:ContactPoint The epo:hasInternetAddress was defined:
epo:hasInternetAddress: The main webpage used by the instance of the concept.
It was noted that the Contract class needs to have its own estimated value, as it is not considered a Procurement Element. This is to distinguish between the Tender value and the Contract value. As a result, the Contract now includes the relation epo:hasContractValue to capture the value associated with the contract. This property is linked to the epo:MonetaryValue class. Additionally, the Contract has a lot reference through the property "epo:hasLotReference" which connects it to the epo:Lot class.
Further discussion is needed to determine how to model Monetary Values with respect to both Contract and Tender.
The Contract class has an Amended Contract subclass. The Amended Contract class inherits all attributes from the Contract class.
The following Notices were discussed, and it was suggested to update the Notice modules accordingly to implement them.
-
Contract Completion Notice Announcement of the completion of a contract The main purpose of this notice is to understand if the contract was completed as set out in the contract award notice (to be published on 2023-06-14 in EU Vocabularies) It was noted that the Completion Notice announces the completion of the Contract, not the Contract itself. Therefore: epo:announcesContract was changed to epo:announcesCompletionOfContract.
-
Pre-Market Consultation Notice Announcement of a pre-market consultation. A pre-market consultation is not a call for competition, and no procurement documents are available at the time of consultation. A consultation may or may not be followed by a future competition (to be published 2023-06-14 in EU Vocabularies).
Action Points
-
Points to be followed up
-
What is the Reference number of the contract
-
The conflict in the definitions of Tender total taxes amount and Tender total amount needs to be addressed.
-
Tender total amount: The total amount of the offered deliverables in the tender excluding all taxes payable by the contracting authority.
-
Tender total taxes amount: The total amount of taxes included in the total amount.
-
-
Contract type is mapped to at-voc:contract-nature codelist (works, service and supplies) in ePO. However in the contract model requirements contract type can also be FA and DPS it should be checked if there is a valid reason for this?
-
Update the Notice modules to implement Contract Completion Notice and Pre-Market Consultation Notice.
-
Working Group meeting 30/05/2023
Date: 30/05/2023
Participants: Natalie Muric, Giampaolo Sellitto.
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Agenda
-
Continue discussing Dynamic Purchasing System (DPS) model
-
Relations and properties definition harmonisation.
-
epo-cat:hasAmount
-
epo:hasValidityPeriod
-
dct:title
-
skos:prefLabel
-
dct:Description
Discussion
During the WGM meeting, the modeling of Award Decisions within the Framework Agreement and Dynamic Purchasing System (DPS) ontology following the previous meeting. Based on this discussion, the following updates were made:
-
epo:announcesLotAwardOutcome was changed to epo:announcesLotAwardDecision.
-
epo:ResultNotice epo:announcesLotAwardDecision epo:AwardDecision should be visible in Notice module
-
epo:comprisesLotAwardOutcome was changed to epo:comprisesLotAwardDecision
The participants defined the following terms and relations:
-
epo:SubmissionStatisticalInformation: Statistical information about submissions on a given competition, either at Lot level or Mini-Competition level.
-
epo:MiniCompetitionAwardDecision: Result concerning the Mini-Competition attributed by the Awarder
-
epo:summarisesInformationForAwardDecision: Relates to submission for the given competition, either at Lot level or Mini-Competition level.
The model below was validated:
Framework Agreement
The participants reviewed and validated the following model:
A Framework Agreement results from a Lot Award Decision, which concerns a specific Lot that uses the framework technique. The Lot Award decision which is used to establish the Framework Agreement specifies the different Qualification Criterion and Award Criterion (Procurement Criterion) to be used. The Mini Competition that may be launched within the Framework Agreement follows the rules set by the Framework Agreement and involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
During the meeting, it was confirmed that technique is used at lot level.
The relation epo:indicatesAwardOfLotToWinner was changed to epo:indicatesAwardToWinner to accommodate the award of mini-competitions.
Furthermore, the participants defined the following terms:
epo:MiniCompetition: A process where multiple winners or candidates of previous stages of a procedure bid for a specific procurement. Additional Information:
It is typically used in framework agreements where the suppliers have already been pre-selected, and the mini competition is used to determine which supplier is best suited for a particular project or contract. It is also used in a Dynamic Purchasing System where the suppliers come from a list of Candidates.
epo:QualificationCriterion: Criterion used in the first stage of procurement.
epo:ParticipationCondition: Criterion that describes a Requirement to take part in a procurement.
DPS:
The DPS diagram below was reviewed and validated by the participants:
A DPS (Dynamic Purchasing System) uses a DPS Technique. In the first stage, the different Qualification Criterion are specified and there is no Award Decision, however a Candidate List is created which lists the economic operators that are admitted to subsequent Mini-Competitions. The subsequent Mini Competitions involve specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
During the WGM, a question was raised regarding whether "epo:DynamicPurchasingSystem" should be a subclass of "epo:system." The decision was to leave it for the time being and if the need became apparent this would be implemented.
-
Additionally, epo:CandidateList was changed to epo:SelectedCandidateList and its definition is updated to the following definition: Record of Candidates admitted to take part in award phases of procurements.
-
epo:Candidate: The Role of an Agent that has sought an invitation or has been invited to take part in a restricted Procedure, in a competitive Procedure with negotiation, in a negotiated Procedure without prior publication, in a competitive dialogue or in an innovation partnership.
Relation and property definition harmonisation.
The following relations and properties occur in the ontology with more than one definition the participants therefore agreed on a common definition for each
epo-cat:hasAmount: The predetermined monetary value charged in addition to the price.
-
epo:hasValidityPeriod: The relation indicating until when a given instance of a concept is applicable.
-
epo:hasCertification: Relation to the proof of conformance.
-
dct:description: An account of the resource. Additional Information: Description may include, but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource.
-
dct:title: A name given to the resource.
-
skos:prefLabel: The preferred lexical label for a resource, in a given language. (it has been added as issue into GitHub)
-
For the relation epo-cat:has Amount one of the relations had a definition and the others not so the one existing definition was pasted in all: The predetermined monetary value charged in addition to the price. After meeting note: however this definition should be further reviewed.
Action
Add the following changes to the ticket titled "Review changes that affect the standard form mappings."
-
epo:announcesLotAwardOutcome was changed to epo:announcesLotAwardDecision.
-
epo:comprisesLotAwardOutcome was changed to epo:comprisesLotAwardDecision
-
epo:indicatesAwardOfLotToWinner was changed to epo:indicatesAwardToWinner.
Working Group meeting 23/05/2023
Date: 23/05/2023
Participants: Natalie Muric, Giovanna Filippone, Martina Pititto, Giampaolo Sellitto
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Agenda
-
Discuss Dynamic Purchasing System (DPS) model
-
Is there an actual Award Decision in the DPS after the Qualification Stage, even if there is no Contract Award Notice?
Discussion
The WGM started by introducing the participants to the scope of the ePO ontology, which aims to provide a formal representation of the concepts, relationships, and entities within the eProcurement domain. It aims to facilitate the exchange of procurement-related information between different systems and organizations, and to support the automation and optimization of procurement processes. The ontology covers various aspects of procurement, such as procurement notification, tendering, contracting, and invoicing and is data oriented.
The modeling of Framework Agreement and Dynamic Purchasing System (DPS) within the ontology was presented.
Framework Agreement
A Framework Agreement results from a Lot Award Decision, which concerns a specific Lot that uses the framework technique. The Lot Award decision which is used to establish the Framework Agreement specifies the different Qualification Criterion and Award Criterion (Procurement Criterion) to be used. The Mini Competition that may be launched within the Framework Agreement follows the rules set by the Framework Agreement and involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:
DPS
A DPS (Dynamic Purchasing System) uses a DPS Technique. In the first stage, the different Qualification Criterion are specified and there is no Award Decision, however a Candidate List is created which lists the economic operators that are admitted to subsequent Mini-Competitions. The subsequent Mini Competitions involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:
Award Decision:
To ensure Award Decisions exist for both the Framework Agreement and the Mini Competitions the Award Decision has become a superclass of Lot Award Decision and Mini Competition Award Decision allowing for the different instantiations required for different use cases. The Award Decision comprises Tender Award Outcome which indicates award of Lot to a winner. These relations are inherited by the Lot Award Decision and Mini Competition Award Decision. See diagram below.
After meeting note: as the Mini Competition inherits from the Award Decision the relation “indicatesAwardOfLotToWinner” needs to be reviewed maybe to “indicatesAwardToWinner”
During the WGM, the relations describesLot and describesMiniCompetition were changed to concernsLot and concernsMiniCompetition respectively. Additionally, the relations, epo:hasRestated AwardedValue and epo:hasRestatedEstimatedValue were removed from the model.
Definitions:
During the meeting, the participants defined the following terms:
-
epo:hasBargainPrice: The value of procured supplies that have used a particularly advantageous opportunity available for a very short time at a value considerably lower than normal market prices.
-
DPS: An electronic System that is set up by a Buyer which lists the Economic Operators that satisfy the Qualification Criteria, which may later be put into competition via a Mini-Competition in view of awarding a Purchase Contract.
-
DynamicPurchaseSystemTechniqueUsage: A Technique that allows the selection of Candidates throughout the Procedure via the Qualification Criteria, followed by individual Mini-Competitions for the Award of Purchase Contracts.
-
ListCanditate: A list of Candidates considered to take part in a restricted Procedure, in a competitive Procedure with negotiation, in a negotiated Procedure without prior publication, in a competitive dialogue or in an innovation partnership.
Working Group meeting 16/05/2023
Date: 16/05/2023
Participants: Natalie Muric, Pietro Palermo, Peter Borresen, Thomas Pettersson.
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Agenda
Harmonization of modules for eCatalogue, eFulfilment, and eOrdering Modules
-
Charge Information - Item Level or Line Level?
-
Item and Batch IDs
-
Organisation and Person Certificates
-
Remodelling epo-ord:DeliveryTerm
Discussion
The working group began by reviewing previous agreements related to eCatalogue, eOrdering, and eFulfilment modules reached in meetings held on April 25, 27, and May 3, 2023.The participants confirmed their consensus on the proposed changes.
-
Removal of epo-cat:hasExternalSpecification property in the epo-cat:item in Catalogue module
-
Standardised namespace prefix for ePO Model (Note: in the text and diagrams in this report the standardised namespace of epo: has not been used as the standardized namespace is to implemented with all other changes.)
-
Renaming epo-cat:ItemDescription to epo:ItemProperty.
-
Replacing epo-ful:hasBaseAmount property with epo:isCalculatedOn in epo-ord:AllowanceChargeInformation and epo-ord:TaxInformation . Replace epo-cat:specifiesItem relationship between epo:Deliverable and epo-cat:Item by inheritance of epo-cat:Item by epo:Deliverable.
-
epo:Contractor and epo-ord:Seller are the same concepts in a Public Procurement.
-
epo-ord:AllowanceChargeInformation will have 3 subclasses: epo-ord:AllowanceInformation, epo-ord:ChargeInformation, and epo-ord:PriceDiscountInformation, because epo-ord:AllowanceChargeInformation is an epo-cat:InformationHub, and it is directly connected to the Line and Document.
-
The VAT rate value will be modeled through epo-ord:TaxInformation epo-cat:hasPercentage and epo-ord:TaxInformation epo-cat:hasTaxCategory. The working group then continued to discuss the points that were seen as contentious previously:
Charge Information - Item Level or Line Level?
During the discussion, participants debated whether the Charge Information should be at the Item level or Line level. To illustrate the point an example of countries where certain charges are associated with food items containing sugar. For instance, if an item is priced at 1 euro, the actual amount paid might be 1.7 euros due to the sugar charge. This charge is applied at the price level.
One suggestion put forward was to have the price at the item level, establishing a direct association between the item and its price. However, after further deliberation, the decision was made to maintain the price at the line level while establishing a reference between the line and the item.
In PEPPOL the price is specified based on the location, and the order reflects the price based on quantities. There are two types of discounts: line-level discounts and price-level discounts. Line-level discounts can be defined as a specific amount per line, such as a discount of 100 euros per line. Price-level discounts, on the other hand, are expressed as a certain amount per unit, such as cents per orange.
As a result of the discussion, it was decided to remove the epo-ord:PriceDiscountInformation element and introduce new associations for enhanced clarity and consistency. The new associations are epo-ord:hasPriceDiscountInformation between epo-cat:Price and epo-ord:isSpecificToOrderLine, as well epo:hasPriceSurchargeInformation between epo-cat:Price and epo-cat:ChargeInformation.
Modeling of Item and Batch IDs
The participants agreed to replace the relation adms:identifier with epo:hasBatchID to improv clarity and consistency. The epo: hasCatalogueItemID is replaced by epo:hasSellerItemID
As part of the discussion, it was agreed to add definitions for all epo:Item and epo:Batch IDs:
-
epo:hasManufacturerItemID: The general identifier assigned to the concept as defined by the manufacturer.
-
epo:hasBuyerItemID: The general identifier assigned to the concept as defined by the Buyer.
-
epo:hasBatchID: The identifier assigned to a specific batch of the produced Item.
-
epo:hasSellerItemID: The general identifier for the concept as defined by the seller.
-
epo:hasSerialID: The identifier assigned to the specific instance of the produced concept.
To illustrate these concepts, an example was discussed: when purchasing a new mobile phone, the seller ID and the manufacturer ID may differ, but a generic buyer ID would be used.
Organisation and Person Certificates
It was agreed upon by the participants to introduce the epo:hasCertification relation between epo:Certificate and epo:Organization, epo:Person, and epo:Item. This new relation allows for the association of certifications with these entities.
Furthermore, the definitions for the following concepts were updated as follows:
-
epo:Certifier: A Role of an Agent that issues a Certificate.
-
epo:Certificate: Proof of conformance of the instance of the concept to a defined set of criteria, ensuring credibility, trust and transparency.
Remodelling epo-ord:DeliveryTerm
During the working group meeting, it was agreed by the participants to rename the entity epo-ord:DeliveryTerm to epo-ord:DeliveryAgreement. By changing the name of the concept there is no conflict with the Term hierarchy of the ontology and the original modelling can be reused. The update was made directly in the meeting.
.
Revising Definitions
The participants revised the definitions with respect to the concepts that were discussed during the meeting.
-
epo-ord:DeliveryAgreement: Term applying to the delivery of goods, services and works. Additional Information: Delivery terms identifier can normally be Incoterms accompanied by the description of specific conditions related to the delivery.
-
epo-cat:InformationHub: Grouping of data that may be associated to various concepts. Additional Information: For example, AllowanceChargeInformation may be associated to the Order or the Catalogue (either at the Line level or at the Document level), amongst others.
-
epo-cat:ChargeInformation: Information about tax, fee or duty imposed. Additional Information: Charge category indicates the nature of the tax/duty/fee, for example VAT, CAR, etc. Charge category modifier may be used in case different levels, exemptions or other modifications apply. The charge can be fixed or relative to the price.
-
epo-ord:AllowanceChargeInformation: Information about discounts, taxes, duties and fees imposed.
-
epo-ord:AllowanceInformation: Information about the discounts imposed.
Action Points:
-
Remove epo-ord:PriceDiscountInformation and introduce new associations:
-
epo-cat:Price epo-ord:hasPriceDiscountInformation epo-ord:isSpecificToOrderLine
-
epo-cat:Price epo:hasPriceSurchargeInformation epo-cat:ChargeInformation.
-
Update definitions for all epo:Item and epo:Batch IDs
-
Organisation and Person Certificates:
-
Update the definition of epo:Certifier and epo:Certificate.
-
Introduce new associations:
-
epo:Person epo:hasCertification epo:Certificate
-
org:Organization epo:hasCertification epo:Certificate
-
epo:Item epo:hasCertification epo:Certificate
Working Group meeting 04/05/2023
Date: 04/05/2023
Participants: Natalie Muric, Peter Borresen, Thomas Pettersson
Model editor: *Andreea Pasăre
*Note editor: Jana Ahmad
Agenda
Goal: Discuss the current status and any potential improvements/harmonisations needed for the eCatalogue, eFulfilment, and eOrdering modules.
-
Discuss removing "postAward" objects and considering them as a document.
-
Also, consider "epo-cat:announcesPostAwardObject."
-
Revise "epo-cat:hasExternalSpecification" property in the "epo-cat:item" object and consider deleting it since we have added "epo-cat:hasExternalSpecification" association between "epo-cat:Item" and "epo:Document."
-
Change eCat:Item to epo:Item
-
Discuss adopting "epo" as a uniform namespace prefix in the ePO model.
-
Revise the naming of "epo-cat:ItemDescription" to align it between modules.
-
Discuss aligning VAT and other tax categories between modules.
-
Propose using "TaxInformation" instead of "hasVATRate" and "hasVATCategory."
-
What is the difference between TaxInformationSchema and TaxInformation?
-
Discuss if "epo-ord:PriceDiscountInformation" and "epo-cat:ChargeInformation" are the same and align them across modules.
-
Propose changing "epo-cat:specifiesItem" to "epo:specifiesDeliverable."
-
Propose adopting "epo-cat:Deliverable" into all modules.
-
Discuss the difference between "epo:Contractor" and "epo-ord:Seller" for all modules.
-
Decide whether "epo:hasSerialID" should be at the Item level or the Batch level.
-
A party should have authorization. This needs to be modeled. Take into account the Certificate as well.
-
Discuss epo-ord:TaxInformation definition.
-
Discuss removing epo-ord:DeliveryTerm.
-
Discuss the proposal to change epo-cat:ItemDescription to 'epo-cat:ItemProperty
-
Considering the possibility of moving 'TaxInformation' to 'epo-cat:Item', but further investigation is required
-
What is the Difference between epo:hasManufacturerItemID and epo:hasSerialID
Discussion:
-
The participants has approved the removal of the "postAwardObject" class and instead considers "postAward" objects as documents for the eOrdering, eCatalogue, and eFulfilment modules.
-
The participants approved to Remove "epo-cat:hasExternalSpecification" property in the "epo-cat:item" in Catalogue class
-
The participants has agreed upon the use of 'epo' as the standardized namespace prefix in the ePO model.
-
The participants has approved changing from 'epo-cat:ItemDescription' to 'epo:ItemProperty'
-
The participants approved that "epo:Contractor" and "epo-ord:Seller" are the same for all modules. However, it still needs to be determined how to incorporate this into the model."
-
epo:hasBatchId, epo:SerialId are different, and they are in Item instances. (TBD 16)
-
The participants discussed the need for parties to have authorization.
-
The relation between person and epo:Certificate should be added
-
-
The participants discussed removing if removing epo-ord:DeliveryTerm will affect eFulfulment model.
-
epo:hasGeneralDeliveryTerm, epo:hasDeliveryTermDescription properties will be added to epo-ord:DeliveryInformation
-
epo:specifiesDeliveryTermLocation relatin will be added between epo-ord:DeliveryInformation and dct:Location
-
-
The participants discussed the ReceiptAdvice
-
There are three type of rejection for recipet
-
In ReceiptLine livel
-
In Consignment Delivery Shipment.
-
TransportHandlingUnit
Action points:
-
"epo:Contractor" and "epo-ord:Seller" are the same for all modules. However, it still needs to be determined how to incorporate this into the model.
-
ReceiptAdvice modeling in eFulfilment epic
Working Group meeting 02/05/2023
Date: 02/05/2023
Participants: Natalie Muric, Ivan Willer, Sellitto Giovanni Paolo
Model editor: *Andreea Pasăre
*Note editor: Jana Ahmad
Agenda:
-
Review Criteria model modifications
-
Review Channel and Contact Point
-
Review Place of Performance: GH 364
-
Review metadata requirements for RDF notices
Discussion:
The WG discussed the Criteria model for standard forms and eforms mappings.
-
at-voc:applicability codelist has been relocated from epo:ParticipationCondition to epo:Contract.
-
A model for instantiating selection criteria has been created to map the conditions for participation and conditions related to contract in a standard form.
-
To ensure that ePO mode meets the requirements for pursuing professional, economic, and technical abilities in the standard form, the epo:ProfessionalSuitabilitySummary, epo:EconomicStandingSummary, and epo:TechnicalAbilitySummary objects have been added to the epo:SelectionCriteriaSummary.
-
The objects epo:ProfessionalSuitabilitySummary, epo:EconmicStandingSummary, epo:TechnicalAbilitySummary are added to epo:SelectionCriteriaSummary to meet suitability to pursue the professional, economic standing and technical ability requirements in the standard form.
-
The properties epo:hasSelectionCriteriaStatedInProcurementDocuments and epo:describesMinimumLevelOfStandards have been added to the epo:SelectionCriteriaSummary object to address the economic and financial standing requirements.
-
The properties epo:describesProfessionRelevantLaw and epo:hasServiceReservedToParticularProfession have been added to the epo:ProfessionalSuitabilitySummary object to provide a list and brief description of the relevant conditions that need to be fulfilled.
-
The property epo:describesObjectiveParticipationRules has been added to fulfill the objective rules and criteria for participation requirement.
-
The property epo:describesDepositsAndGuaranteesRequired has been added to address the requirement for deposits and guarantees.
-
epo:hasPaymentArrangementand epo:hasEPayment properties is in epo:ContractTerm which satisfy main financing conditions and payment arrangements and/or reference to the relevant provisions governing them.
-
epo:hasOrganisationGroupType is added to epo:ContractTerm to fulfil information abut staff responsible for the performance of the contract.
-
epo:hasReservedExecution in epo:Contract satisfies the execution of the contract is restricted to framework of sheltered employment programmes
-
epo:describesDepositsAndGuaranteesRequired and epo:describesVerificationMethod: properties are added to the epo:ParticipationConditionsSummary object to satisfy Qualification for the system requirement.
Working Group meeting 27/04/2023
Date: 27/04/2023
Participants: Natalie Muric, Christian Mondini Consrzio, Ivan Willer, Pietro Palermo, Sellitto Giovanni Paolo, Wim Kok. Thomas Pettersson
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Agenda
Goal: Discuss the current status and any potential improvements/harmonisations needed for the eCatalogue, eFulfilment, and eOrdering modules.
-
Discuss removing "postAward" objects and considering them as a document.
-
Also, consider "epo-cat:announcesPostAwardObject."
-
Revise "epo-cat:hasExternalSpecification" property in the "epo-cat:item" object and consider deleting it since we have added "epo-cat:hasExternalSpecification" association between "epo-cat:Item" and "epo:Document."
-
Change eCat:Item to epo:Item
-
Discuss adopting "epo" as a uniform namespace prefix in the ePO model.
-
Revise the naming of "epo-cat:ItemDescription" to align it between modules.
-
Discuss aligning VAT and other tax categories between modules.
-
Propose using "TaxInformation" instead of "hasVATRate" and "hasVATCategory."
-
What is the difference between TaxInformationSchema and TaxInformation?
-
Discuss if "epo-ord:PriceDiscountInformation" and "epo-cat:ChargeInformation" are the same and align them across modules.
-
Propose changing "epo-cat:specifiesItem" to "epo:specifiesDeliverable."
-
Propose adopting "epo-cat:Deliverable" into all modules.
-
Discuss the difference between "epo:Contractor" and "epo-ord:Seller" for all modules.
-
Decide whether "epo:hasSerialID" should be at the Item level or the Batch level.
-
A party should have authorization. This needs to be modeled. Take into account the Certificate as well.
-
Discuss epo-ord:TaxInformation definition.
-
Discuss removing epo-ord:DeliveryTerm.
-
Discuss the proposal to change epo-cat:ItemDescription to 'epo-cat:ItemProperty
-
Considering the possibility of moving 'TaxInformation' to 'epo-cat:Item', but further investigation is required
-
What is the Difference between epo:hasManufacturerItemID and epo:hasSerialID
Discussion:
-
The WG has approved the removal of the "postAwardObject" class and instead considers "postAward" objects as documents for the eOrdering, eCatalogue, and eFulfilment modules, at least for now. Further discussion is required for the eOrdering module.
-
The proposal is to consider po-ord:OrderResponse as the type of epo-ord:Order, but further discussion is required.
-
-
The WG approved to Remove "epo-cat:hasExternalSpecification" property in the "epo-cat:item" in Catalogue class
-
The WG has agreed upon the use of 'epo' as the standardized namespace prefix in the ePO model.
-
The WG has approved changing from 'epo-cat:ItemDescription' to 'epo:ItemProperty', but we need to check the inheritance with 'epo-elementDescription'.
-
Discuss aligning VAT and other tax categories between modules.
-
Change the property from "epo-ful:hasBaseAmount" to "epo:isCalculatedOn" in both "epo-ord:AllowanceChargeInformation" and "epo-ord:TaxInformation".
-
-
Allowance Charge Information and related information to be discussed later
-
epo-ord:AllowanceChargeInformation epo-ord:LineAllowanceInformation, ord:LineChargeInformation at line and header level
-
epo-ord:PriceDiscountInformation in price level.
-
-
The WG approved that "epo:Contractor" and "epo-ord:Seller" are the same for all modules. However, it still needs to be determined how to incorporate this into the model."
The WG discussed the Difference between epo:hasManufacturerItemID and epo:hasSerialID
-
Manufacturer Item Id is the Identifier of item in manufacture side.
-
Serial Id is the Identifier of instance of item.
-
The WG proposed to have epo:hasBatchId in item instance level.
-
The WG discussed the need for parties to have authorization.
-
The WG has approved the proposal to have a certificate for organizations, but further discussion is needed for Items.
-
-
Discuss Removing epo-ord:DeliveryTerm
-
We should keep DeliveryTerm in contract
-
For eOrdering: we should consider the following diagram
-
epo:hasGeneralDeliveryTerm, epo:hasDeliveryTermDescription properties will be added to epo-ord:DeliveryInformation
-
epo:specifiesDeliveryTermLocation relatin will be added between epo-ord:DeliveryInformation and dct:Location
-
epo-ord:DeliveryTerm needs further discussion.
-
Action points:
-
The WG has approved changing from 'epo-cat:ItemDescription' to 'epo:ItemProperty', but we need to check the inheritance with 'epo-elementDescription'.
-
Change the property from "epo-ful:hasBaseAmount" to "epo:isCalculatedOn" in both "epo-ord:AllowanceChargeInformation" and "epo-ord:TaxInformation".
-
Create a diagram for Allowance Charge Information and related information
-
Draw tables for all terms and definitions for Batch, Item, Identifier.
Working Group meeting 25/04/2023
Date: 25/04/2023
Participants: Natalie Muric, Veit Jahns
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Agenda
Goal: Discuss the current status and any potential improvements/harmonisations needed for the eCatalogue, eFulfilment, and eOrdering modules.
-
Discuss removing "postAward" objects and considering them as a document.
-
Also, consider "epo-cat:announcesPostAwardObject."
-
Revise "epo-cat:hasExternalSpecification" property in the "epo-cat:item" object and consider deleting it since we have added "epo-cat:hasExternalSpecification" association between "epo-cat:Item" and "epo:Document."
-
Change eCat:Item to epo:Item
-
Discuss adopting "epo" as a uniform namespace prefix in the ePO model.
-
Revise the naming of "epo-cat:ItemDescription" to align it between modules.
-
Discuss aligning VAT and other tax categories between modules.
-
Propose using "TaxInformation" instead of "hasVATRate" and "hasVATCategory."
-
What is the difference between TaxInformationSchema and TaxInformation?
-
Discuss if "epo-ord:PriceDiscountInformation" and "epo-cat:ChargeInformation" are the same and align them across modules.
-
Propose changing "epo-cat:specifiesItem" to "epo:specifiesDeliverable."
-
Propose adopting "epo-cat:Deliverable" into all modules.
-
Discuss the difference between "epo:Contractor" and "epo-ord:Seller" for all modules.
-
Decide whether "epo:hasSerialID" should be at the Item level or the Batch level.
-
A party should have authorization. This needs to be modeled. Take into account the Certificate as well.
-
Discuss epo-ord:TaxInformation definition.
-
Discuss removing epo-ord:DeliveryTerm.
Discussion:
-
The WG Discussed removing "postAward" objects and considering them as documents, and also consider removing the 'epo-cat:announcesPostAwardObject' relation in the following modules.
-
eNotice
-
eOrdering
-
eCatalogue
-
eFulfilment
-
-
The definition of epo-cat:Catalogue is changed to: A Document describing a set of Items offered for purchase that can be processed in an electronic way.
-
It is noted that Catalogue is part of the Contract
-
The WG approved to Remove "epo-cat:hasExternalSpecification" property in the "epo-cat:item" in Catalogue class
-
The WG has agreed upon the use of 'epo' as the standardized namespace prefix in the ePO model.
-
The WG has proposed a change from 'epo-cat:ItemDescription' to 'epo-cat:ItemProperty'.
-
Should we retain both 'epo-cat:ChargeInformation' and 'epo-ord:PriceDiscountInformation', or are they identical in meaning?
-
The WG discussed the validity or appropriateness of using "epo-ord:PriceDiscountInformation" in the context of epo-cat:Price level.
-
The WG has agreed to keep 'epo-ord:PriceDiscountInformation' as part of the 'epo-cat:Price' level.
-
-
The WG deliberated on whether epo-cat:ChargeInformation aligns with the "epo-cat:Price" or "epo-cat:Line or epo-cat:Item level components.
-
The WG is considering the possibility of moving 'TaxInformation' to 'epo-cat:Item', but further investigation is required
-
-
-
The WG has agreed to the proposal of using 'TaxInformation' as an alternative to 'hasVATRate' and 'hasVATCategory'.
-
The WG has reached an agreement to eliminate 'epo-cat:specifiesItem' between 'epo-cat:Item' and 'epo:Deliverable', and to consider 'epo:Deliverable' as a type of 'epo-cat:Item'.
-
The WG discussed the optimal location of 'epo:hasSerialID' at Item or Batch Level.
-
The WG has proposed to remove epo:hasSerialID and use epo:hasManufacturerItemID.
-
-
The definition of epo-ord:TaxInformation is changed to Information about the imposition of mandatory levies required by law.
Action Points:
-
Replace 'epo-ord:concludesContract' between 'epo:Contract' and 'epo-ord:OrderResponse' with 'epo-ord:implementsContract'.
-
We need to create a model that encompasses all the documents that form part of the Contract.
-
Revise 'Deliverable' in the context of eContract
Working Group meeting 11/04/2023
Date: 11/04/2023
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Agenda
Continue discussing 1st draft of eContract Model with respect to the initial contract information requirements.
-
To continue from Award of the contract
Discussion
The WG continued to discuss and model the Award of the Contract in the eContract module, specifically in relation to the requirements for initial contract information. Our methodology involves assessing whether the following requirements are already covered by ePO. If they are, the working group will map them to ePO. If they are not covered, they will be implemented as follows. The bullet points represent the initial contract information requirements, while the sub-bullets indicate their mapping to ePO.
Award of the contract
-
Award identifier:
-
adms:identifier of the epo:AwardDecision
-
-
Award date
-
epo:hasAwardDecisionDate (type is changed to xsd:dateTime)
-
-
Award time
-
epo:hasAwardDecisionDate (type is changed to xsd:dateTime)
-
-
Winner economic operator
-
epo:Winner
-
-
Economic operator name
-
dct:title on the foaf:Agent
-
-
Economic operator identifier
-
epo:hasRegistrationCountry from org:Organization to at-voc:country
-
-
Documents
-
epo:Contract epo:associatedWith epo:Document
-
-
Attachment identifier
-
adms:identifier on epo:Document
-
-
Attachment description code
-
At-voc-new:document-type
-
-
Attached document
-
we do not provide the binary object, only URL (epo:hasAccessURL on the epo:Document)
-
-
Deliverable offered
-
epo:specifiesDeliverable epo:Item
-
-
Deliverable name
-
dct:title on the epo:Item
-
-
Deliverable description
-
dct:description on the epo:Item
-
-
Delivered quantity
-
epo-cat:hasQuantity from epo:Deliverable to epo:Quantity
-
-
Deliverable total amount:
-
epo:hasContractValue relation is created between epo:Contract and epo:MonetaryValue
-
-
epo-con:ContractAmendment object is created with:
-
epo:emendsContract relation with epo:Contract.
-
epo:hasContractAmendmentDate property.
-
epo:providesUpdatedContractValue relation with epo:MonetaryValue
-
epo:hasContractAmendment relation with epo:Contract
-
-
Contract Roles class is created to specify all roles that participant in Contact
Working Group meeting 04/04/2023
Date: 04/04/2023
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Discussion
The WG revised the order, catalogue, fulfilment modules from the document level perspective.
The WG continued to discuss and model the eContract module, specifically in relation to the requirements for initial contract information. Our methodology involves assessing whether the following requirements are already covered by ePO. If they are, the working group will map them to ePO. If they are not covered, they will be implemented as follows. The bullet points represent the initial contract information requirements, while the sub-bullets indicate their mapping to ePO.
The WG decided to consider Contract as a Document
-
Legal references:
-
epo:haslegalBasis
-
epo:hasLegalReferenceDescription is added
-
-
Award criterion type:
-
epo:Lot specifies Procurement Criterion (epo:specifiesProcurementCriterion) epo:AwardCriterion
-
-
Criterion sandbox is created to clarify the relationship between procedure, lot, criterion, at-voc:legal-basis. at-voc:legal-basis, epo:legal-regime are moved to epo:ProcurementObject
-
epo:PlannedProcurementPart is not epo:ProcurementObject.
-
epo:foreseesProcurementObject relation is added between epo:PlannedProcurementPart and epo:ProcurementObject.
-
Tender identifier
-
epo:includesTender from epo:Contract to epo:Tender
-
epo:hasLotReference
-
-
Tender digest
-
epo:hasElectronicDigest relation is created between documents.
-
-
Tender signature
-
epo:ElectronicSignature object is created with epo:hasElectronicSignature relation to epo:Document.
-
dct:description property is added to epo:ElectronicSignature object
-
-
Tender total amount:
-
epo-ord:hasTotalTaxInclusiveAmount
-
-
Tender total tax amount:
-
epo-ord:TaxInformation Action:
-
-
Map contract, document wrt top level ontology
-
To move from epo:ProcurementElement the following suggested documents:
-
Tender
-
AwardDecision
-
ReviewObject
-
-
Discuss Tender total tax amount and Tender total amount from initial contract information requirements.
Working Group meeting 21/03/2023
Date: 21/03/2023
Participants: Natalie Muric, Wim Kok, Giampaolo Sellitto
Model editor: Andreea Pasăre
Note editor: Jana Ahmad
Discussion:
WG discussed the eContract model, mainly the initial contract information requirements:
-
epo-con: announces contract exists between epo:Contract and epo-con:ContractDocument. It was noted that Contract document is not a contract, it is maybe some additional things such as metadata. What is in the contract is in the contract document.
-
An Excel document is created in sharepoint including Contract related concepts and their definitions.
-
epo:bindsBuyer relation created between contract and Buyer.
-
epo:signedByBuyer relation is created between Buyer and contractDocument
WG did a Mapping between Contract model and initial contract information requirements:
-
Issue date, time and identifies should be in the document
-
isSubjectToContractSpecificTerm relation is created between contract and ContractTerm
-
Procurement project type: is contract-nature on ContractTerm
-
Description of Extension and option: epo:ContractTerm has epo:hasOptionsDescription data property. Duration is considered to be about Options.
-
Period start date, Period start time: contractTerm defines the contract period.
-
qt-voc:cpvsuppl is removed
-
CPV: at-voc:cpv enumeration is added.
-
CPV supplementary: is not included in ePO
-
Project execution location: epo:ContractTerm defines place of performance which is dct:location
-
Procurement project lot: Contract and lot class is created.
-
Lot identifier:
-
epo:hasTenderReference relation is renamed between contract and tender.
-
epo:hasLotReference relation is renamed between contract and lot.
-
Working Group meeting 28/02/2023
Date: 28/02/2023
Participants: Ahmed Abid, Wim Kok, Natalie Muric, Csongor Nyulas, Sellitto Giovanni Paolo
Model editor: Andreea Pasăre, Eugen Costetchi
Note editor: Jana Ahmad
Discussion
GH 370
-
To be closed only after we get confirmation that (and perhaps a link to) an issue asking for the introduction of appropriate code(s) in the at-voc:direct-award-justification vocabulary was opened with DG GROW.
GH 431
-
hasRestatedAwardedValue: This is wrongly modeled and applied in the mappings. It will be updated in the context of modeling eContract. To be discussed in RDF meeting
Procedure and sub-procedure:
-
WG decided to:
-
Separate a procedure from its scope
-
Drop down plan into its phases.
-
-
Notes from WG:
-
Procedure itself is a plan.
-
It is not correct to use process concept to refer to plan/procedure.
-
Nothing is to be executed in procedure, it is just a plan
-
Lot is referring to purpose.
-
-
Plan hierarchy model
-
Lot is procurementScope not a ProcurementObject
-
-
SelectioCriteria and ExclusionGround are specified for LotQualificationPhase
-
Lot Plan composition model contains the phases/stages of procurement lifecycle
-
Overall plan composition model
-
Note, if we have hundreds of lots and anything is applied to one lot it will be applied to all lots in the same procedure (to be discussed later).
-
We should find a better term than LotPreAwardLifecycle/Workflow.
Working Group meeting 07/02/2023
Date: 07/02/2023
Participants: Jana Ahmad, Natalie Muric, Csongor Nyulas
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi
Agenda
-
Standard form mappings - ePO GitHub issues:
-
GH 422 Missing fields F21, IV.2.5, IV.2.9
-
-
Procedure/Sub-procedure
Discussion
GH 442
In the context of concession contracts, the award of procedure actually means procedure. So the “scheduled date for start of award of procedure” is the start of the procedure. We should look into the Directive 2014/24/EU for a better understanding.
Procedure versus sub-procedure
The term procedure has been conflated.
Question: What is a procedure?
Answer: A description of steps taken by someone, a plan.
This plan acts as a general plan for multiple Lots. There are specific plans per each Lot, but the general plan should be fine-tuned in order to cover all the Lots.
Within a procurement project we can have a procedure type. Each lot should be executed once or multiple times according to the procedure type.
There are procedural things that are open to all Lots. We can think about it as a procurement procedure.
Some actions/events are reusable within a procedure:
-
Buyer calls for competition [object] (publish Competition Notice)
-
Buyer awards [object] (and publish a Contract Award Notice)
-
Buyer (re-)opens a (mini-)competition [object]
The negotiation action can be part of the competition.
Also, WG discussed re-usable process fragments:
-
Qualification (exclusion grounds and selection criteria)
-
Competition
eAuction and mini competitions are subsets of closed competition.
Some important examples of procedure types are discussed:
-
Restricted procedure:
-
Buyer calls for competition [specific-object] (Competition Notice)
-
Qualification
-
Closed-Competition [specific-object]
-
Buyer awards [specific-object] (Contract Award Notice)
-
-
Restricted procedure with eAuction
-
Restricted procedure with Dynamic Purchasing System
The competition is related to award criteria and the qualification is related to exclusion grounds and selection criteria. All the process fragments should take into consideration the criteria and the appropriate objects.
Plan versus execution
A differentiation between a plan and an execution is discussed.
-
A Plan (~Procedure + Lots) is a detailed proposal for doing or achieving something.
-
Goal: award of a contract
-
-
An *Execution (~ProcedureExecution) *represents the carrying out of a plan, order or course of actions.
-
Achievement: award of a specific contract.
-
We can have procedure executions per Lot (for a Lot there may be one or multiple executions)
-
We can have procedure-executions per Lot. For a lot, there may be one or multiple executions.
There is one execution for the whole procedure.
-
Each lot has one or multiple procedure executions within the “frame” of the “Procedure” execution.
Procurement purpose is split into Lots, and NOT the procedure that is split into lots.
Working Group meeting 31/01/2023
Date: 31/01/2023
Participants: Jana Ahmad, Laszlo Ketszeri, Natalie Muric, Csongor Nyulas, Giampaolo Sellito, Marc Christopher
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Discussion
The WG discussed: Candidate role: This role exists in ePO version 2.0.2 as epo:CandidateShortList have the following definition: “The tenderers that have been selected in a two stage procedure.
Additional information: the types of procedures that this shortlist applies to are restricted procedures, competitive procedures with negotiation, competitive dialogue procedures and innovation partnerships. The WG approved the previous definition and additional information on (WG 27/07/2018).
epo:EconomicOperatorShortList is a superclass for CandidateShortList. This concept has the following definition: “The Economic Operators that are considered for a given procedure”. The WG approved the previous definition on (WG 22/08/2019).
A new role was added for the next ePO release, epo:Candidate, with the following definition: “The role of an agent that has expressed interest to participate in a competition. The WG approved the previous on (WG 31/01/2023).
The concept is a subclass of epo:OfferingParty as depicted in the diagram below:
Buyer role refinement: The buyer may need to be further refined into AwardingBuyer and AcquiringBuyer, similarly as it is done for the CPB.
GH 421:
Section III.1.* of F21 refers to Selection criteria.
-
Section III.1.4: Objective rules and criteria for participation refers to description in requirement.
-
Codelist to be used in at-voc-applicability.
-
epo:hasreservedProcrument added to ParticipationCondition.
-
epo:hasReservedExcution added to ContractTerm Section III.2. *“contract performance conditions” refers to ContractTerms.
In the eForms they are at the Lot level, but in the standard forms they are at the Procedure level? They are in fact “criteria summaries” for Procedure level
-
Section III.2.1: information about a particular profession refers to ContractTerms
-
information about a particular profession should be mapped to selection criteria summary:
-
In selectionCriteriasummary object two properties are added
-
Eop:hasProfessionRelevantLaw
-
epo:isReservedToParticularProfession
-
BT-79 - III.2.3 - information about staff responsible for the performance of the contract
-
isResponsibleStaffNameIsrequired property is created in ProcrumentCriteriasummary object
-
Two enumerations are added to SelectionCriterien object
-
epo:hasPerformingStaffQualificationInformation is added to epo:ProcurementCriterien
Question: Does SelectioncriteriaSummary inherit from SelectionCriterien?
-
Yes, So then, ProcrumentCriteriaSummary inherits from ProcrumentCriterien.
-
To be checked, when reworking on the Criteria & Criteria Summary: if epo:isReservedToParticularProfession: is the same as the one in the epo:ContractTerm.
Working Group meeting 24/01/2023
Date: 24/01/2023
Participants: Jana Ahmad, Laszlo Ketszeri,, Natalie Muric, Csongor Nyulas, Giampaolo Sellito
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi
Discussion
GH 119
-
When we have missing mapping in the technical mapping but the data exists in the standard forms, then we should add the remark in the RDF output as a rdfs:comment. ==== GH 418
-
The generalisation statement between a role and its type (AcquiringParty, SellerParty or AuxiliaryParty) should not be present in the technical mapping.
-
This ticket and https://github.com/OP-TED/ted-rdf-mapping/issues/289 were closed, with the same resolution.
GH 419
The property epo:hasLotAwardLimit has been deleted.
epo:hasMaximumNumberOfLotsToBeAwarded is kept.
GH 420
-
In the standard form, we have just generalised information (generalisation criterion) at the procedure level.
-
And the procurement criteria is specified for the lot level .
-
In the standard form, procedure specifies criteria summary (so we can have summary criterion at the procedure level .).
-
We should differentiate between criteria and criteria summary
-
Create participation criterion class in a lot level (so we have 4 criteria now).
-
Participation is at the submission level.
-
Participation conditions should be even before submission
-
Two approaches for Criteria modelling (concept and instance diagrams) have been presented and are depicted below.
Example 1
Example 2
-
Submission terms:
-
Submission terms: rules for submission
-
Submission terms has participation condition
-
Participation conditions had reserved procurement.
-
-
Create criteria summary diagram to differentiate between procurement criteria and procurement criteria summary:
-
If the procurement criteria goes to the procurement object, Ground exclusion is the same for all lots.
-
Giampaolo suggests adding relation between Selection Criteria and Selection Criteria Summary (aggregation relation).
-
-
Decided to model the following:
Working Group meeting 17/01/2023
Date: 17/01/2023
Participants: Jana Ahmad, Natalie Muric, Pietro Palermo, Thomas Pettersson, Giampaolo Sellito, Emidio Stani, Ivan Willer
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi
Discussion
-
Org ontology link: https://www.w3.org/TR/vocab-org/
Core Vocabularies observations
-
epo:hasOrganisationUnit should be an attribute on the OrganisationalUnit concept from org ontology.
-
If we follow org ontology we need to add a new class where to put only an attribute for the name.
-
The reason why we conflated these two is the case when only a particular unit is the Buyer.
-
Recommendation to not separate these two concepts (Organisation and Organisation Unit) and only rename the attribute to epo:hasOrganisationUnitName
-
Why? Because the Agent that takes a role (e.g. Buyer) can be a Unit or an organisation, but we decided to set the description at the “organisation level”.
-
-
epo:hasLegalFormType - from SEMIC perspective we asked the OP to create the Core Vocabulary for the classification of the legal forms from GLEIF:
-
This will be published in the future.
-
Switch to using a code list for legal type classifications.
-
cv:LegalEntity versus epo:Business
Definition for cv:LegalEntity:
A self-empoyed person, company, or organization that has legal rights and obligations.
Definition for epo:Business:
A private law company registered in a national registry.
-
epo:Business should be a subclass of cv:LegalEntity in Core Business Vocabulary.
-
In order to align with Core Voc, it means we need to add cv:LegalEntity and org:FormalOrganization between org:Organization and epo:Business.
-
But a Business has to be a FormalOrganization.
-
In CPOV, a PublicOrganisation is not org:FormalOrganisation, but it is directly under org:Organisation.
-
Depending on the country, a cpov:PublicOrganisation may have a legal entity, so it may be a formal organisation.
-
Hierarchy
-
Org:Organisation
-
cv:PublicOrganisation
-
org:FormalOrganisation
-
legal:LegalEntity (self-employed person, company, or organisation with certain rights)
-
Action: Replace epo:Business by cv:LegalEntity
-
-
-
epo:OrganisationGroup
-
-
-
We need to have a discussion on whether the legal form type is at the legal entity level or at the organisation level.
-
What if we have the case when a tenderer is a public organisation?
-
-
This relationship is used at the Organisation level because foaf:Agent includes also a person or a system.
-
Decided to remove the relation from epo:OfferingParty to epo:Business as depicted in the diagram above.
-
Checking on whether we had a formal organisation in older versions of ePO 2.0.1 and it was not.
-
But in 12th May 2020 WGM minutes it appears to have been created an epo:FormalOrganization concept: https://docs.ted.europa.eu/epo-wgm/notes/2020-05-12-wgm.html
Concession contract
-
In CPSV-AP the cv:ServiceConcessionContract was added as a subclass of epo:ConcessionContract:
-
For CPSV-AP we need a relationship between epo:Contract to epo:ContractSpecificTerm (epo:hasContractTerm) in order to be able to get to the at-voc:contract-nature:
-
Contract includes specific terms
-
Contract cannot have epo:ContractSpecificterms
-
Contract “includes Lot”, is not right, needs more discussion on this.
Order
-
Look into the syntax binding, where we will see all the “elements” that we need to see in the order.
-
For example, Contract ID, is missing, or what is in the Buyer? It is hard to see all the elements from the ePOcore or eCatalogue, or eFulfillment.
-
Request: can we have a plain table with all properties for a class (including inherited attributes).
-
Technical Question:
-
Given a UML model, can we generate an “application profile” in a tabular representation (see SKOS-AP-EU ), for each class considering also inheritance.
-
Can we also automatically generate a “Path” to get that property?
-
-
-
It was found that a epo:ProcurementElement does not have an identifier, so the relation between epo:ProcurementObject and epo:Identifier was moved from epo:ProcurementElement to epo:Identifier as depicted in the diagram below:
-
Proposal to work on a table that contains all the properties for all the concepts in the Order phase on the 26th Jan.
Working Group meeting 10/01/2023
Date: 10/01/2023
Participants: Jana Ahmad, Vladimir Alexiev, Emiel Dhondt, Juris Kalejs, Wim Kok, Natalie Muric, Giampaolo Sellito, Emidio Stani
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Discussion
Core Vocabularies observations
cpv:Person
-
data type is Changed from rdfs:Literal to rdf:langString in the following properties :
-
foaf:name
-
foaf:familyname
-
foaf:givenName
-
person:patronymicName
-
dct:alternative
-
-
cv:deathDate Removed from cpv:Person.
cpov:ContactPoint
-
epo:hasInternetAddress is similar to contactPage with foaf:Document as range.
-
Proposal by Core Vocabularies to change the range to anyURI so this contactPage can be adapted by ePO as well.
-
Based on the standard forms, epo:hasInternetAddress is probably the URL of the Organization and not of the ContactPoint.
-
Proposal to add epo:hasHomePage (xsd:anyURI, [0..*]) as an attribute on org:Organization concept with the following definition: “The main web page.”
cv:Channel
-
epo:hasDescription is similar to http://purl.org/dc/terms/description
-
If we change the datatype to LangString, we need to change them all.
-
rdfs:Literal allows integers, booleans and LangString, etc.
-
We need to revise data types and make them more specific.
-
Better to use rdf:PlainLiteral, see GitHub ticket: https://github.com/OP-TED/ePO/issues/405
-
Instead of epo:hasDescription switch dct:description.
-
epo:hasURL is mandatory property, but it should not be, because sometimes we might need to use epo:isAdhocChannel.
-
In standard forms AdhocChannel is not a boolean, but in eForms it is.
-
The AdhocChannel should not be CommunicationMean.
-
An Organization hasCommunicationMeans either a Channel or a DeliveryGateway.
epo:AgentInRole
-
The attribute epo:hasTitle was changed to dct:title and the definition modified accordingly.
epo:Identifier
-
WG discussed whether to use dct:identifier instead of epo:hasID.
-
But dct:identifier has a range of rdfs:Literal and can not be used.
-
We need to decide on whether to change to adms:identifier (old github issue: https://github.com/OP-TED/ePO/issues/258)
-
If we need more properties for ePO we should add a ticket to adms.
euBusinessGraph Semantic Data Model
-
https://docs.google.com/document/d/1dhMOTlIOC6dOK_jksJRX0CB-GIRoiYY6fWtCnZArUhU/edit#
-
Presenting the reg org vocabulary: https://www.w3.org/TR/vocab-regorg/
locn:Address
-
All attributes data types are changed from rdfs:Literal to rdf:langString, except locn:postCode and locn:locatorDesignator.
CCCEV
On cccev:Requirement:
-
cccev:description changed to dct:description (rdf:PlainLiteral).
-
cccev:identifier changed to dct:identifier.
-
We need to use an identifier for requirements.
-
To stay consistent to how identification is realised in ePO, we switched to using adms:identifier instead of dct:identifier as per CCCEV requirement.
-
Instead of cccev:name we will use skos:prefLabel (rdf:PlainLiteral).
-
There should be only one description and we added as additional information that we can have multiple languages for the same description. (see https://www.w3.org/TR/skos-reference/#L1567)
-
On cccev:type changed to dct:type
-
On cccev:InformationConcept, hasDescription and hasTitle are changed to dct:description and skos:prefLabel.
WG disscussed the Channel
-
In standard form we have the following section for communication:
-
We want to use the AdhocChannel as a URL and not a boolean.
-
We might need to remove epo:hasAdditionalInformation and epo:hasName from cv:Channel.
-
In CPVS-AP, cpsv:PublicService has a cv:Channel.
-
We need to do a comparison to version ePO 2.0.1.
-
Adding epo:hasToolsAccessURL (xsd:anyURI, [0..1]) attribute to epo:AccessTerm concept with the following definition: “Web page where the tools and devices for electronic communication that are not generally available can be downloaded free of charge.”
-
This needs to be further discussed.
-
cv:Channel was moved from org:Organization level to epo:AgentInRole level.
-
In PEPPOL, an endpoint is an identifier.
-
The cv:Channel class was deleted.
-
We need to further discuss the difference between epo:Business and cv:LegalEntity.
Any comments on the documentation?